1. Field of the Invention
The embodiments of the invention generally relate to web services (WS), and more particularly to the orchestration of composite web services in constrained data flow environments.
2. Description of the Related Art
Web services are self-contained, self-describing, modular applications that can be published, located and invoked across an internet such as the World Wide Web. Web services encapsulate information, software or other resources, and make them available over a network via standard interfaces and protocols. They are based on industry standard technologies of Web Services Description Language (WSDL) (to describe), Universal Description, Discovery, and Integration (UDDI) (to advertise and syndicate), and a Simple Object Access Protocol (SOAP) (to communicate). Web services enable users to connect different components within and across organizational boundaries in a platform and language independent manner. New and complex applications can be created by aggregating the functionality provided by existing web services. This is referred to as “service composition” and the aggregated web service is known as a “composite web service”. Existing web services involved in composition are known as “component web services”. Web service composition enables businesses to interact with each other and process and transfer data to realize complex operations. Furthermore, new business opportunities can be realized by utilizing the existing services provided by other businesses to create a composite service.
Composite web services may be developed using a well-known specification language such as Business Process Execution Language for Web Services (BPEL4WS), Web Services Integration and Processing Language (WSIPL), Web Service Choreography Interface (WSCI), etc. and may be executed by an engine such as Websphere Business Integration Server Foundation Process Choreographer or Business Process Execution Language for Web Services Java® Run Time (BPWS4J), both available from International Business Machines, Armonk, N.Y., USA. Java® is a registered trademark of Sun Microsystems, Santa Clara, Calif., USA. Typically, a composite web service specification is executed by a single coordinator node. It receives the client requests, makes the required data transformations (modification or utilization of the output data of a component web service or input data received from the client before it is fed as input to the next component web service or sent back to the client), and invokes the component web services as per the specification. This mode of execution is referred to as “centralized orchestration”. However, in certain scenarios, businesses and individuals (i.e., clients making the request) might want to impose restrictions (i.e., data constraints) on access to the data they provide or the source from which they can accept data based on their policy.
Centralized orchestration can lead to the violation of these data constraints as the central coordinator (i.e., entity facilitating the dissemination of the client's data between/among third parties) has access to the output data of all the component web services. Moreover, existing methods of data encryption and authentication generally fail here, as the centralized coordinator needs access to the output data of all the component web services for applying the necessary data transformations. These data flow constraints, thus, present obstacles for web service composition. Further, use of centralized orchestration can lead to performance (throughput, response time, scalability) degradation due to a centralized coordinator bottleneck and the occurrence of unnecessary data copying.
For example, a third party administrator such as an insurance agent 101 that provides an insurance claim service is shown in FIG. 1. In this case the customer (patient) 103 submits the request to the agent 101, which provides the hospital 105 and insurance company 107 details of the patient's request, and the agent 101 settles the claim by interacting with the web services of the hospital 105 and insurance company 107, respectively. Without any data flow constraints, agent 101 can create the composite web service using centralized orchestration. Thus, upon receiving a request from the patient 103, the agent 101 contacts the hospital web service 105, gets the medical records, passes it on to the insurance company web service 107, and receives an acknowledgement of claim settlement upon completion thereof. However, in a real world scenario, the hospital web service 105 might want to maintain confidentiality of the medical records and reveal them only to the patient 103 or to the insurance company web service 107 directly. Furthermore, the insurance company web service 107 might not want to accept medical records from any intermediary and only directly from the hospital web service 105 to ensure accuracy and authenticity of the records, for example. These data flow constraints prohibit the use of centralized orchestration to create this composite web service.
Data flow constraints are typically handled through encryption and related security mechanisms in distributed systems. There have been many efforts to compose new applications from existing components. However, most of these have been restricted to closed systems (or intra-enterprise networks) where security and data flow constraints are not of paramount concern as the composition consists of known and trusted components residing inside a trusted, perhaps internal, domain. Composition of autonomous services across the Internet to create new applications “on the fly” is a relatively new phenomenon that has been enabled by the emergence of web services. This composition raises issues in security, privacy, and authenticity of data previously ignored.
Information flow policies are used to specify confidentiality and integrity requirements and control the “end-to-end” use of data in a secure system. Secure program partitioning is a language based technique for protecting confidential data during computation in distributed systems containing mutually untrusted hosts. Confidentiality and integrity policies are expressed by annotating the programs with confidentiality labels. The program can then be partitioned automatically to run securely on heterogeneously trusted hosts. Decentralization is a relatively new technique for orchestrating composite web services, although it has been applied in earlier approaches for enabling distributed workflow execution.
Web services security is an active area of research and much effort is being directed in deriving specifications including WS-Security, WS-Policy, WS-Trust, and WS-Privacy of which only WS-Security has been specified in detail. WS-Security describes ways of attaching security tokens, signatures, and encryption headers to SOAP messages. WS-Policy describes a general-purpose model and corresponding syntax to describe and communicate the policies, capabilities, requirements, and preferences of a web service. WS-Trust describes trust models to enable web services to securely interoperate. WS-Privacy describes a model that enables web services to state their privacy preferences and organizational privacy practice statements.
The conventional specifications are generally concerned with aspects of security, privacy, and trust between the client and the web services or between two web services. Composition of third party web services requires a rich set of data transformations to be applied in between the sequential invocations of component web services. This typically cannot be accomplished in a generic way using centralized orchestration. Furthermore, security and encryption mechanisms defined in WS-Security and other related specifications can help adherence to data flow constraints using centralized orchestration only in limited scenarios. For example, in the case where the component web service is capable of encrypting only the critical data values and need not encrypt the entire body of the SOAP message, service composition can be performed using centralized orchestration if this data (in its encrypted form) can be fed as input to the next component web service without any data transformation and/or utilization.
In other situations, where the centralized coordinator node might need access to the output data of one of its component web services in order to provide a more valuable composite service by utilizing that data, or where the entire output message of a component web service is encrypted, centralized orchestration using WS-Security mechanisms generally cannot be used effectively. In the insurance agent example described above and illustrated in FIG. 1, the insurance agent 101 might need to look at the medical records to decide which insurance company (i.e., there may be multiple insurance companies from which to select) he/she should forward the records to (a dental insurance company or a general health insurance company, for example). The agent 101 cannot do this using centralized orchestration with encrypted data for the reasons described above.
Furthermore, centralized orchestration tends to lead to unnecessary traffic on the network as all data is transferred between the various components via the coordinator node instead of being transferred directly from the point of generation to the point of consumption. This generally leads to poor scalability and performance degradation at high loads. Therefore, there remains a need for orchestrating composite web services in constrained data flow environments without the use of a centralized coordinator.